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PREFACE 


The first 4 months of the STS/Spacelab Payload Utilization Planning 
Study under Contract NAS8-31146 defined a process for translating 
payload requirements into firm flight assignments. This effort 
was documented in MDC G5987, STS/Spacelab Payload Utilization 
Planning (S/SPUP) Study, Phase I Final Report. 


At the end of the fourth month, NASA redirected the study from 
development of scheduling software to concentration on the planning 
aspects of the problem. The study guidelines changed accordingly. 
NASA furnished a baseline description (master flow and management 
framework) of an STS Utilization Planning (SUP) system. The goals 
of the remainder of the study were to simplify this baseline where 
possible, define its products, and determine the resources required 
to operate it. The result of this in-depth development was to be a 
specification describing the system and its implementation. 

In the course of performing this work, the different aspects of the 
SUP system were discus sed with the NASA operations centers 
(JSC, KSC, and GSFC). In addition, progress was reported 
regularly to the NASA Steering Group for Payload Operations 
Concepts Studies, and the recommendations of the Steering Group 
were incorporated as additional guidelines. 

This report presents a summary description of a process for 
STS/Spacelab payload utilization planning and recommendations 
on its products and implementation. 

It should be noted that subsequent to the completion of the study 
analysis effort, but prior to final documentation, certain roles 
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and missions within NASA were redefined. As a result, the 
overall SUP master flow and management framework will be 
updated in the Integrated Payload and Mission Planning (IP&tMP) 
Study which supersedes SUP, This will include deletion of 
separate Integrated Missions Planning and Analysis (IMAP) 
reports for each mission as recommended in this study and 
incorporation of their basic function into the remaining IP&MP 
documentation. The basic results are valid; however, it is 
recommended that a premission planning process be started 
soon for the early 1980's missions. This will require some 
updating of the process definition by the IP&MP Study. The 
deletion of the IMAP's as a discrete product and the updating 
of the process by the IP&MP Study are expected to reduce the 
manpower requirements identified in this report. 

Questions regarding this report may be directed to: 

o R. L. Brown, COR, S/SPUP Study 
NASA/ Mar shall Space Flight Center 
PM-01 

Marshall Space Flight Center, Alabama 3 5812 
Telephone (205) 453-0461 

o R. E. Holmen, Manager, S/SPUP Study 
McDonnell Douglas Astronautics Company 
13-2 

Huntington Beach, California 92647 
Telephone (714) 896-4694 
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Associate Administrator 

Change Control Board 
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Engineering Change Request 
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Integrated Payload and Mission Planning 
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Office Management Budget 

Office of Planning and Program Integration 
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Payload Ghangeout Room 

Preview Cargo Manifest 
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Payload Operations Control Center 

Program Operating Plan 

Payload Planning Data Bank 
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PRR 

QR 

RID 

ROM 

SCI 

SFOP 

SPDA 

SPRAG 

SSPPSG 

S/SPUP 

STS 

SUP 

SURE 


Preliminary Requirements Review 
Quick response 
Review Item Discrepancy 
Rough Order of Magnitude 
Schedule- Critical Item 
Spaceflight Operations Plan 
STS Payload Data Analysis 

STS Payload Requirements and Analysis Group 
STS Payload Planning Steering Group 
STS/Spacelab Payload Utilization Planning 
Space Transportation System 
STS Utilization Planning 
STS Utilization Review Board 
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Section 1 
INTRODUCTION 


The Space Transportation System (STS) Utilization Planning (SUP) process 
will provide the means by which the orbital flight requirements of the 
national space program can be translated into definitive plans for STS and 
payload development, procurement, operations, and support leading to 
authorization and funding of STS and payload project activities. 

The STS is intended to be operated continuously by NASA for an indefinite 
length of time, perhaps several decades. With projected flight rates as 
high as 60 per year, the system will perform many different kinds of 
missions for many different users. Many of the needs that the system 
must meet will be defined only in approximate terms at the time when STS 
utilization planning is required. For' example, STS development or procure- 
ment lead-time requirements may predate authorization of payloads and 
missions requiring those STS resources. 

Thus, planning for utilization of the STS must not only account for the 
complexities of the transportation system, the payloads, and the supporting 
functions. It must also be able to cope successfully with uncertainty. 
Payloads that are likely to emerge in the future as well as those that have 
already been authorized must be accounted for, and allowance must be made 
to respond to contingencies such as payloads that are not ready on time, 
missions that are aborted and must be rescheduled, and emergencies that 
demand the servicing of payloads in orbit or the rescue of personnel from 
space . 

In addition, the utilization-planning process must provide a means for 
coordinating the planning of many different NASA entities. Numerous organi 
zations at the Centers and Headquarters will be involved in payload develop- 
ment, STS operations, and mission support, and the plans prepared by these 
organizations must be compatible and mutually supportive. 



"Finally, to be compatible with the way the Government does business, the 
SUP process must be synchronized with the NASA and federal planning, 
budgeting, and authorization cycles. 

This report describes the planning process recommended to meet these 
requirements which was developed according to the guidelines and objectives 
noted in Table 1. 

Section 2 of this report summarizes the rationale and primary products 
of STS utilization planning. Section 3 provides an overview of the process 
which is further defined in Section 4, Section 5 summarizes the implementa 
tion of the system. The report concludes with Section 6 which summarizes 
the major recommendations resulting from the study. 
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Table 1 

GUIDELINES AND OBJECTIVES FOR THE SUP PROCESS 


Guidelines 


The SUP process shall: 

• Be consistent with the Government-furnished baseline 
master flow and management concept. 

• Do planning to the s chedule- critical item (SCI) level. 

• Help coordinate planning which cuts across two or 
more program or Center interfaces, 

• Provide long-range planning which encompasses the 
operational lifetime of the STS (nominally 12 years). 

• Emphasize planning within a 6-year horizon, 

• Support translation of payload concepts from long- 
range planning into the approval and implementation 
phase. 

• Be limited to preliminary and long-range planning: 
detailed mission and flight planning or detailed 
scheduling and assignment of STS resources shall be 
performed by the appropriate Operations 

Office /Centers. 

• Be as simple as possible requiring a minimum of 
new resources, new documentation, or changes to 
current pr ocedures , planning, and reporting methods 
and cycles. 

• Be coordinated with the operations centers during its 
development to assure the end product is useful to 
them. 


concept for SUP was 


Objective.*^ 


• To provide direct support to the agency's 
planning for utilization of the STS/Spacelab 
(payloads, missions, and integration). 

• To provide a central point for compilation, 
validation, and integration of payload 
requirements and to serve as the focal point 
for the payload community in dealing with 
the carriers on interface matters. 

• To help the user to get his requireme'nts 
properly included in planning. 

• To assure the operating plans and forward 
planning of the various NASA centers with 
respect to utilization of the Space Trans- 
portation System are mutually compatible. 

• To maximize utilization of the STS while 
minimizing inventory. 

• To provide visibility for overall NASA 
program planning. 

• To recommend compatible grouping of 
payloads for flight. 

• To maximize STS utility and assure pay- 
load interface requirements are accommo- 
dated in a timely manner. 

• To minimize total system cost. 


fui'nished by the Government as a baseline for the study. 


Section 2 

STS UTILIZATION PLANNING 


2. 1 RATIONALE 

The goal of the STS is to provide convenient and economical access to space. 
The SUP process is designed to assist in the achievement of this goal by- 
enabling the STS to furnish rapid- response transportation even though m.any 
of the associated activities require long- lead-time planning and procurement. 

The purpose of the SUP process is to perform long-range planning that 
anticipates traffic and provides the guidance necessary to plan the operations 
in detail. Six specific items were identUied as requirements in this context 
(Table 2). 

The first item is a catalog of potential payloads that can be used by the NASA 
Centers as a basis for planning. Convenient access to information concern- 
ing these payloads also should be provided so that the Centers are all able to 
work from the same set of data. An easily updated data base accessible 
from all of the Centers is the best way to ensure that the most up-to-date 
information is available without developing a large and cumbersome paper 
system. 

Long-range traffic projections are needed to establish what accommodations 
will be required in the future. This is pai'ticularly important for the develop 
ment of long- lead- time items such as facilities and for visibility of future 
budget requirements. The best approach to providing this visibility is to 
assemble the payloads in the catalog into logical cargoes and to schedule 
them for agency- wide consideration. 

Short-range traffic must be considered as an integral part of long-range 
planning. If the STS is to have a quick- response capability, a mechanism 
must be provided for accommodating payloads that are not identified in time 
to be included in the normal planning cycle. This can only be done if cargo 


Table 2 


RATIONALE FOR STS UTILIZATION PLANNING 
# The goal of the STS is to provide convenient and economical access to space 


• SUP addresses this goal by doing what is necessary to help assure agency- wide planning 
is done as efficiently as possible 


What Does NASA Need 

Why Is It Needed 

How Can This Best Be Provided 

A catalog of potential 
payloads and their 
description 

To provide a consistent 
set of data for planning 

By a convenient, easily updated data base 
system accessible to all 

Long- range traffic 
projections 

To help establish what 
accommodations will be 
needed in the future 

By accumulation of payload data into cargoes 
for agency- wide consideration 

A mechanism for quickly 
including payloads in 
upcoming flights 

Accommodating short- 
lead- time payloads is a 
Shuttle objective 

Through planning by providing margins and 
flexibility 

A baseline of projected 
traffic for definitive 
planning 

To assure agency-wide 
plans for the STS are 
mutually compatible 

By preparing a common baseline for planning 
supported by analysis and updated by opera- 
tions plans of the centers 

Data which accurately 
describes each mission 

Positive control of mis- 
sions is dependent on how 
well controlled items are 
described and understood 

By developing a common, top-level mission 
description from which lower-level docu- 
mentation can flow 

Assessment of impact of 
new payloads on interfaces 

Interface requirements are 
critical to proper develop- 
ment of STS hardware 

By examining all payload requirements on a 
centralized basis to derive common 
requirements 


space lias been provided. Thus, long-range planning must anticipate 
quick- response traffic by providing adequate cargo- space margins and 
flexibility to accommodate changes. 

Probably the most important item needed by NASA for long-range STS 
utilization planning is an agency-wide baseline of projected traffic. This is 
necessary so that the Centers, in planning operations and procurement for 
the STS, can all work under a consistent set of guidelines to produce mutually 
compatible plans. However, mere publication of a baseline for planning 
does not guarantee responsible planning unless sufficient analysis has been 
performed to ensure that (1) the operations associated with the baseline 
traffic are compatible with available resources and (2) the schedule results 
in efficient resource utilization. 

The operational concept for the STS requires definitive premission planning 
and, because of the cost of operations, positive control over payloads, 
mission parameters, and schedules. Therefore, the missions baselined 
for planning must be described in a manner that will provide the Centers 
with the information that they need to plan their activities, furthermore, 
this mission information must be specific in the areas that will be placed 
under management control upon approval. Thus an agency- wide set of 
top-level mission descriptions is needed, and this set of descriptions must 
be structured so that it encompasses (or at least provides a basis for) the 
development of lower- level control documentation. 

The sixth item needed by NASA for long-range STS utilization planning is an 
integrated assessment of the impact that the payloads included in planning 
will have on the STS. This is particularly important during the STS develop- 
ment phase. If the planned payloads are not compatible with the STS or its 
operations, then the best method of accommodation (change the STS, change 
the payloads, or develop interfacing equipment or software) must be 
established. 

2.2 MAJOR SUP PRODUCTS (see Table 3) 

The Payload Model satisfies the need for a common catalog of payloads. 

This model covers payloads up to 12 years in the future to give both 
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Table 3 

SUP PRODUCTS 

Product Description 

Payload Model'I' Compilation and description of firm and 12-year 

projected payloads, desired launch year and 
orbits, data source, and sponsor 

Traffic Model* Summary cargo manifest for each flight 

(12-year horizon), by year, site, payloads, 
orbits, STS elements needed, load factors/ 
margins, contingency missions, and total 
cost projections 

Quick- Response Flight Quick- response payload description, ground and 
Request flight requirements flight opportunity analysis, 

accommodations plan, flight assignment and 
approval 

Planning Baseline Synposes of missions and payload projects 

planned over the next 6 years, contingency 
traffic provisions, preliminary flight schedule 
options and STS utilization assessments, 
integrated program milestones, and cost 
projections 

Integrated Mission Description of the payloads and their integrated 

Analysis and Planning mission operations and requirements for a given 
(IMAP's)** cargo manifest 

Integrated Payload Collective assessment of the time- phased inter- 

interface Requirements face requirements (to STS) of the payloads listed 

and Accommodations in the Payload Model, definition of related MMSE 
Assessment needed to accommodate interface 


What It Provides 


P. catalog of potential 
payloads and their 
descriptions 

Long-range traffic pro- 
jections and associated cost 
projections 


A mechanism for quickly 
identifying candidate 
flights 


A coordinated baseline of 
projected traffic for defini- 
tive planning whose feasibil- 
ity is established 


Data which accurately and 
succinctly describe each 
mission and can be a basis 
for lower-level control data 

Assessment of impact of 
new payloads on interfaces 


*These documents have been published — see TMX 647 51 
**IMAP's for several early Shuttle missions have already been developed 
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short- and long-term visibility for planning. In order to ensure that the 
Payload Model is as realistic as possible, inputs are requested from the 
NASA payload Associate Administrators (AA's) and from non-NASA STS 
users twice a year (January and June). These payloads are defined in a 
consistent manner, and information regarding them is stored in a Payload 
Planning Data Bank (PPDB) that is easily accessible from all of the Centers. 
The Payload Model is updated yea.rly (1) to augment the data in the current 
Project Approval Documents (PAD>$), which identify approved NASA pay- 
loads; (2) to reflect the status of current pgyload projects; and (3) to 
incorporate new payloads approved for planning by the payload AA's. 

The Traffic Model satisfies the need for a usable long-range traffic pro- 
jection. It presents summary cargo manifests and preliminary mission 
schedules (1-year granularity) for traffic during the operational lifetime 
of the STS. The cargo manifests are made up from the payloads in the 
Payload Model. Allowance for "extra" missions to react to contingency 
situations and for "open" cargo manifests to accommodate emergencies 
and targets of opportunity are included, along with load- factor margins 
for quick- response payloads. Summary cost and funding projections for 
payloads and transportation in terms of cost per flight and non- NASA pay- 
load reimbursements are also included. The development of the Traffic 
Model provides the mechanism for combining and scheduling payloads to 
form optimum cargoes. The Traffic Model is published yearly after 
coordination with the appropriate AA's. 

Quick-response (QR) payloads are payloads which, because of a target 
opportunity, program anomaly or other factors need to be flown sooner 
than they can be accommodated by the normal planning process. Rather 
than place them in a queue to wait for the next compatible flight available, 
the Quick- Response Flight Request is used to initiate identification of one 
or more suitable flights. The request is divided into three parts. Part I 
is the request by the user, Part II covers the results of flight opportunity 
analysis, and Part III is the flight assignment, which represents a com- 
mitment by the STS to fly that payload on a specific flight. 
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If the payload can be accommodated without impacting mission cost or 
schedule, the payload originator is placed in contact with the cognizant 
Mission Manager for approval and integration. If a flight opportunity does 
not exist, the payload can be put on standby for assignment as space becomes 
available. For payloads that impact cost and schedules, it is suggested that 
they be referred to a Headquarters Level I STS Utilization Review Board 
(SURE) which would be responsible for approving assignment of payloads to 
flights and flight assignments. The SURE membership should be made up 
of representatives from all NASA functions concerned with STS operations • 
and should include the Payload AA's. 

The Planning Baseline furnishes the information necessary to ensure that 
agency- wide planning is based on a common reference and that the resulting 
plans of the Centers for the STS are mutually compatible. A primary function 
of the Planning Baseline is to provide a convenient means for annual intro- 
duction of new payloads into the planning process. The baseline describes 
firm and projected traffic (including contingency forecasts) within a 6- year 
planning horizon and includes preliminary schedules and resource utilization 
profiles. It serves as a common point of departure and provides planning 
data for the organizations that must procure for, plan for, and implement 
the missions included in the plan. The Planning Baseline is approved by 
the SURE. 

Integrated Mission Analysis and Planning (IMAP) documents satisfy the need 
for mission descriptions that can he controlled. The IMAP's provide payload 
and cargo definitions, system requirements and interfaces, mission param- 
eters (trajectories, orbit descriptions, etc. ), and ground and flight operations 
sequences and required support. The IMAP's augment the data in the PAD 
(which generally are not sufficiently detailed for planning) to provide mission 
data in support of agency- wide planning for utilization of the STS. 

The Integrated Payload Interface Requirement and Accommodation Assessment 
document presents, on a collective basis, the requirements of the payloads 
listed in the Payload Model a.nd an assessment of the ability of the STS to 
accommodate them. These requirements are time- phased according to the 
schedule data available in the Traffic Model and provide an envelope of 
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interface requirements imposed by all payloads on the STS. This document 
is published yearly in separate volumes for each major interface, e. g. , 
Interim Upper Stage, Spacelab, and Orbiter. The document is coordinated 
throughout NASA and Europe (as appropriate) by the STS Payload Require- 
ments and Analysis Group (SPRAG) and the Joint Users Requirements Group 
(JURG), and is validated by the STS Payload Planning Steering Group. 
Validated interface requirements that are common to several payloads are 
accommodated by the carrier (Spacelab, Orbiter, etc. ) or by multiple- 
mission support equipment (MMSE). Unique interface requirements are 
accommodated by payload- peculiar interface and support equipment. The 
Integrated Payload Interface Requirement and Accommodation Assessment 
document will be maintained during STS development to ensure that a com- 
prehensive set of payload interface requirements is being imposed. When 
the STS becomes operational, this document will be updated when (and if) 
new classes of payloads impose significant new interface requirements. 



Section 3 

OVERVIEW OF THE SUP PROCESS 


The STS utilization planning process has been designed to satisfy the 
objective defined in Table 1 by performing the following functions: 

• Timely accumulation of requirements for payloads and their 
missions and translation of these into traffic projections for the 
STS. 

• Maintenance of a common payload/mission data base and operations 
baseline whose use helps assure mutual compatibility among the 
various Centers' detailed planning for payload activities and STS 
operations. 

• Development, coordination, and timing of the above data such that 
its availability is compatible with the planning necessary to support 
the Government's planning and approval cycle. 

To minimize the development of new planning elements to perform the above 
functions, the existing NASA- wide planning network and its products were 
used as much as possible. 

3. 1 ACTIVITY FLOW 

The relationship of the elements of the SUP process is illustrated in 
Figure 1. 

The SUP process starts with the accumulation of requirements from various 
researchers and agencies who wish to have their payloads flown by the STS. 
For quick- response (QR) payloads, a Quick- Response Flight Reqaest is 
prepared. Upon approval, the QR payloads are referred to appropriate 
NASA operational elements for. integration and flight. The remaining 
payloads are assembled into the Payload Model, which lists all payloads 
approved for use in planning. As new payloads are identified for inclusion 
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in planning, descriptive data for each are entered on STi? Payload Data 
Analysis (SPDA) sheets and are included in the Payload Planning Data Bank 
(PPDB) accessible from the various Centers. 

Cargo manifests, which consist of logical groupings of payloads and flight 
equipment for each STS flight, are then established. The year in which each 
cargo is to be flown is identified, and a cost assessment is performed that 
provides rough- order- of- magnitude (ROM) cost estimates for the NASA pay- 
loads and equipment and for the STS transportation costs assigned to each 
payload (NASA and non-NASA). The cargo manifests and their schedules 
are then combined with the cost assessments and published as the Traffic 
Model. The Traffic Model provides visibility with respect to anticipated 
traffic and corresponding costs to NASA for the operational lifetime of the 
STS. 

For the payloads in the Traffic Model, the data in the PPDB are used to 
develop (or update) the Integrated Payload Interface Requirements, which 
present the envelope of payload-to-STS interface requirements to be imposed 
on the STS. For requirements that cannot be readily accommodated by 
modifying the current configuration of the STS or the payloads in the PPDB, 
an MMSE Plan is prepared that describes the support equipment projects 
needed to provide interface "bridges. " 

For new cargoes identified in the Traffic Model, an IMAP document is 
prepared. The IMAP establishes mission feasibility and describes the pay- 
loads and their integrated mission operations arid requirements for individ- 
ual STS flights. The IMAP also provides a preliminary definition of items 
to be covered by Bevel I control. 

The traffic within the 6- year planning horizon is then assessed to determine 
its impact on STS flight schedules, resource utilization, key program mile- 
stones, and NASA cost projections. This is done only to the level necessary 
to (1) assess the compatibility to project schedules and the feasibility of the 
STS supporting them and (2) to show how this traffic can be accommodated 


within resource constraints and Headquarters guidelines. The traffic and 
transportation requirements, the preliminary flight schedule options, the 



resource utilization assessments, and the integrated program milestones 
and cost projectioho'become the SUP Planning Baseline. When approved by 
Headquarters, the Planning 'Baseline serves as a common point of departure 
and reference for detailed planning thr o'ugiterW Agency emphasizing long- 
range aspects and supported by analyses sufficient tb'’'qK^pne that it embodies 
an achievable set of requirements. 

The Centers use the Planning Baseline and the Program Operating Plan (POP) 
guidelines provided by NASA Headquarters to perform their detailed planning 
for payloads and operations. This activity results in the Centers establishing 
the POP's necessary to support the traffic projections in the Planning Baseline. 
The plans for STS operations that are developed to support the POP's, when 
integrated, become the Space Flight Operations Plan,'!' which is defined by 
JSC as the NASA Agency-wide "umbrella" for operations planiiing and (1) 
describes how the STS will support the projected traffic, (2) presents the 
flight schediiles, (3) defines STS resource utilization, and (4) identifies STS 
procurement and development requirements . Any discrepancies that are 
revealed in the POP process are rectified in the next year's issue of the 
Planning Baseline. The "horizon" of the Planning Baseline is set at 6 years 
so as to extend past that of the POP (5 years ). Thus, new, long-range 
requirements entering the planning can be assessed and updated at least 
once before they entered the POP, and then could be iterated yearly to bring 
them within guidelines by the time firm budgets were required. 

The NASA budget request is made up from the POP's. When the primary 
payload projects associated with a mission are approved by a means of a 
Project Approval Document (PAD), a Mission Manager is selected. He 
translates the Cargo Manifest and IMAP for his flight into a Flight Manifest 
that summarizes the items on his flight that are under Level 1 and II control. 
When detailed flight planning has matured, he prepares a Flight Approval 
Document that summarizes the technical, programmatic, and safety data 
necessary to secure flight approval. 


*The Space Flight Operations Plan is a 5 -year horizon "work-to" plan pro- 
posed by JSC. It is assumed to be the major interface from the SUP long- 
range planning activities to the STS operators ' planning efforts . 
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3.2 ACTIVITY SCHEDULING 

A primary function of the SUP process is to provide a convenient means for 
introducing new requirements so that Agency-wide planning for operations 
is comprehensive and current. 

Plannhig of operations covers a 5-year span and is documented in a Space 
Flight Operations Plan. Two years in advance, integrated operations sup- 
port planning for authorized flights commences and becomes rnore detailed 
as time to lift-off decreases. The culmination of STS Utilization Planning 
is the Planning Baseline which provides the data to initiate this process. 

The Baseline’s horizon extends beyond that of the Space Flight Operations 
Plan so that planning for new payloads can be iterated yearly. Long-range 
plans that exceed fiscal limits can thus be brought within guidelines by the 
time firm approval is required. The Planning Baseline, by "leading" the 
Space Flight Operations Plan, also provides the long-range visibility of 
space flight operations planning that is necessary to accommodate contin- 
gencies, changes, and quick- r esponse payloads. 

In order for the SUP process to provide the baseline information necessary 
for Agency planning, its activities must be compatible with each other and 
with the NASA POP cycle and the Federal government's new fiscal timetable. 
SUP activities are scheduled to support these cycles and to provide appropriate 
lead time to react to decisions (or problems that are uncovered) in the approval 
cycle. In general, the SUP process provides sufficient planning lead time in 
these cases such that resultant requirements for change do not have to be picked 
up until next year's round of planning. However, the timing of SUP activities 
does not preclude reaction within the current planning cycle if neces sary.. 

Figure 2 illustrates the timing of the Government's fiscal cycle, current 
NASA Headquarters timing of related activities (with SUP approvals added), 
and the interfacing SUP schedule. For the purpose of discussion, a single 
SUP cycle will be described with the related events denoted by the closed 
triangles (A). This cycle covers a 2-year period with SUP activities 
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i 

I ; preliminary planning which picks up the next succeeding year is already 

I ; unde rway. ❖❖ 

1 ■ 
j 

I The SUP cycle starts with the January release, by the AA's, of payload 

! ■ lists. These lists describe new payloads under consideration. These pay- 

j 

I ; loads are then added to those already in the Payload Model from the current 

I : SUP planning cycle. During the next 3-1/2 months the total set of payloads 

; is analyzed, grouped on a preliminary basis and a '“preview" cargo manifest 

(PCM) published in May. This PCM is tentative and is intended to provide a 
preliminary reference for 'uitiating development of associated IMAP's; 

I simulation of the process revealed that in order to prevent "spikes" in man- 

! : power loading, work on IMAP's needs to be started as soon as possible, 

i ' Note that the preview cargo manifest comes out a month after the Planning 

I ; Baseline for the previous planning cycle has been released. The PCM thus 

I ■ gives a preview of what payloads /cai'goes will be added to planning sub- 

j ' sequent to the current plan in process; if any of these payloads or cargoes 

I - are of high priority, time is still available to include them in the current 

i 

I !; plan. 


'-i'The analysis and simulation of the SUP process done as part of the study 
revealed that this time span is required to perform the required work and 
secure the necessary approvals, 

’l<'l<The simulation required development of software which would model the 
entire SUP process considering parallel planning activities. The simu- 
lation allowed a determination of resource requirements and exposed such 
things as bottlenecks and manpower peaks so that readjustment could be 
made to smooth out operations. Constraining operations to meet interme- 
diate milestones also was included in the simulation to assure that the 
resultant SUP process is in consonance with the Government' s budget and 
approval cycles. Because of the unique features developed in this simu- 
lation, it W 3 -S repo'rted to NASA in accordance with the New Technology 
clause of the contract. 
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Figure 3. Sequence of Events for a Single SUP Cycle (Based on Study Simulation) 
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The Jiily x*elease of the AA's payload list and any other payloads that have 
been identified outside the Agency are then added to the Payload Model. 

Upon Headquarters approval of the Payload Model in August, and using 
Headquarters -furnished guidelines, 3 months are available to finalize the 
Traffic Model for future planning. Note that at this point the Space Flight 
Operations Plan of the previous planning cycle has been released to support 
initial budget negotiations in October. 

The Traffic Model is released in mid-November and upon approval and 
receipt of Headquarters planning guidelines, development of the Planning 
Baseline is initiated. The preliminary plan and forward planning years (see 
Figure 4) from the plan that just entered the Govermnent' s approval cycle 
ax*e updated to be consistent with the latest Traffic Model, and the new 
(sixth) year out at the far end of the horizon is added. This effort covers a 
5 -month period and is timed to accommodate information from the January 
POP call and budgetary planning wedges from the comptroller. It also can 
react to changes in forward planning in response to Congressional hearings. 

The Planning Baseline is released in April for a mid -May approval. This 
allows the operations Centers four months to update the Space Flight Opera- 
tions Plaix in advance of their budget request in October. This schedule also 
allows time for new interface requirexrxents to be analyzed and, if required, 
new MMSE identified for inclusion in budgetary planning. 


3.3 QUICK-RESPONSE PAYLOAD PROCESS 

Quick-response (QR) payloads are separately funded and, because they are 
developed on constrained schedules, are usually simple in nature and easy 
to integrate with the STS. (Many, in fact, are of the carry-on "suitcase" 
type and x'equire only minimal support from the STS Orbiter or the Space - 
lab. ) QR payloads are accommodated by the process illustrated in Figure 5. 
A QR Flight Request (Figure 6 ) is first initiated. The flight-request forxri 
is sixnple, yet when SPDA sheets are attached, it contains all information 
necessary to approve the payload for a flight and to document the approval. 
Upon completion of the Pax*t I of the form and Level A SPDA sheets a 
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Figure 4, Overlap of STS Utilization Planning and Space Flight Operations Planning Horizons 
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lit lOf /t 




Figure 6. Quick-Response Flight Request 
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sponsor (an individual within NASA who can help the payload originator 
progress through the approval cycle) is designated by an appropriate center 
representative of the Office of Planning and Program Integration (OPPI) a flight- 
opportunity analysis performed and Level B SPDA sheets are then prepared. 
These data are then submitted for approval. When the flight opportunity analysis 
has identified a suitable flight, space is tentatively reserved, and if the payload 
does not impact mission costs or schedules, the payload originator is put in con- 
tact with the flight's Mission Manager for approval and integration of the payload 
into the mission. The OPPI is notified of the assignment, and when the payload 
is accepted and approved by the Mission Manager, the flight manifest is updated. 
If a flight opportunitydoes not exist but the schedule permits waiting for space 
and/or mission time to be vacated by another payload that fails to meet its 
schedule, the quick- response payload owner is directed to the Director of STS 
Operations who can accept the payload as a standby option. 

If a quick-response payload involves changes to STS costs or schedules, 
or if the schedule can only be met by preempting an existing flight assign- 
ment, the requirement for flight is referred to the STS Utilization Review 
Board, which maintains Level I control over the flight manifests. The 
SURB approves (or disapproves) the requirement and STS operations organ- 
izations are notified of the final arrangements. As before, if no suitable 
flight can be found for a QR payload it can be handed off to the Director of 
STS Operations as a standby option. 
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sponsor (an individual within NASA who can help the payload originator 
progress through the approval cycle) is designated by an appropriate center 
representative of the Office of Planning and Program Integration (OPPI) a flight- 
opportunity analysis performed and Level B SPDA sheets are then prepared. 
These data are then submitted for approval. When the flight opportunity analysis 
has identified a suitable flight, space is tentatively reserved, and if the payload 
does not impact mission costs or schedules, the payload originator is put in con- 
tact with the flight's Mission Manager for approval and integration of the payload 
into the mission. The OPPI is notified of the assignment, and when the payload 
is accepted and approved by the Mission Manager, the flight manifest is updated. 
If a flight opportunitydoes not exist but the schedule permits waiting for space 
and/or mission time to be vacated by another payload that fails to meet its 
schedule, the quick- response payload owner is directed to the Director of STS 
Operations who can accept the payload as a standby option. 

If a quick-response payload involves changes to STS costs or Schedules, 
or if the schedule can only be met by preempting an existing flight assign- 
ment, the requirement for flight is referred to the STS Utilization Review 
Board, which maintains Level I control over the flight manifests . The 
SURE approves (or disapproves) the requirement and STS operations organ- 
izations are notified of the final arrangements. As before, if no suitable 
flight can be found for a QR payload it can be handed off to the Director of 
STS Operations as a standby option. 


/VrCDOfS/fS/El^L. OOUGLAS 




23 


DEFINITION OF THE SUP SYSTEM 


4. 1 PRODUCT DEVELOPMENT 


The SUP system assembles the data needed for planning and processes it for 
yearly publication in appropriate documents (Table 4). The majority of these 
documents have been published in the past (e.g. . Payload Model, T^^a-ffic 
Model, Interface Requirements, and IMAP's). In the future, the SUP system 
will synchronize the development and publication of these documents so that 
they support coordinated planning for the STS. SUP itself has been designed 
to be synchronized with the current NASA Program Operating Plan (POP) 
planning and budgeting cycles and the NASA Payload List releases in January 
and June of each year, and utilizes these as basic inputs to its planning 
process. 


An important tenet of the SUP study was that development of new documenta- 
tion should be minimized, and that where documentation was necessary, 
current or planned documentation should be used if possible. In this sense, 
the existing Payload Model and Traffic Model, slightly enhanced, are incor- 
porated into the STS utilization planning process with scheduled annual 
updates and approval cycles . The existing IMAP reports are further defined, 
placed into the context of the SUP process and cycle, and related to mission 
planning, approval, and control. Payload interface requirements documents 
are defined and related to validation procedures and to the generation of STS 
impacts (RID' s and EGR's) and to the MMSE Plan. 

The Quick-Response Flight Request is a new item, but it is very brief and 
simple. The Flight Manifest and Flight Approval Document are new, but are 
essentially abstracts of the IMAP and other control documents. The Flight 
Manifest and Flight Approval documents, while identified in the SUP study, 
are not part of the SUP process itself, but rathei' are part of the mission 
implementation and control process. 
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STS UTILIZATION PLANNING RELATED 
ELEMENTS AND PRODUCTS 


t'Unnmd Tlementa 

Product a 

Product I>cst ript.on 

K.xi sting or 
I'nder 

Deve lopmrni 

New 

Accun\ulatinn and Maintenance 
of Payload Deacrlptiona and 
Kequirentent* for Plittht 

)*ayload Data 

Ail paylo.ids whuh have been appro\e<l 
for use in planning STS act vities 




STS Payload Data 
Analyais ISPDA) 
Sheet ■ 

Deta led descnpt'Ons •> payloads in 
the payload model uneri as a standard 
payload reference for agent v-w:dr 
planning 




Payload Planning Data 
Pank iPPDIt) 

Centralised "library ' of payload data 
accessible from all centers 

o 



Quick Keaptmae ('light 
it equeat 

A simple form used to get a flight 
assignment and approvr.l for a quick 
response payl >ad 


O 

Interface Requ* rement « and 
Accommodation Afseaainents 

Integrated Payload 

Interface 

Requi rements 

Presents the envelope of interface 
requirements (paylo.td to SIS) for 
payloads in the traffic model. Imposes 
accommodation re<|Uirements on the 
STS 

u 



Multiple Miaaion 
Support tMMSEl Equip- 
ment Plan 

A rlefinit'on of support equipnient 
needed t<> satisfy integrated inter- 
face requirements which cannot be 
mure readily accommodated by 
modifying the current STS configura- 
tion i>r indwidual payloads 

1) 


Traffic Model Development 
(Ca{3ture/Coat Analyaia) 

Carg > Mainfesta 

A logical gtonping of rayloads and 
flight eq'jioment for a single STS flight 

o 



Coat Aaieaament 

Rough order of magnitude (ROM) csti 
mates of the cost of il) p.iyloads m the 
vargo manifests and <^) their transnorta- 
tiur. The ROM costs are used to 
evaluate scheduling of cargo M'snifests 
wit.i respect to cost guidelines. 

o 



Traffic Model 

Cargo manifests and iheir schedules 
coupled with the rust assessment. Pro- 
vides visibility with respec t to antici- 
pated traffic ior the operational life lime 
of the STS 

o 


IVvelopmunt of Miaaitm and 
Flight Deac npt ons and 
Control Data 

Integrated Mission 
Analysis k Planning 
iJM AP) l')ocument 

A dracription of the payloada and their 
integr.ited misaion operaticMis and 
retiuircments for individual STS flights. 
Establishes mission feasibility and nro- 
\tdes a preliminary definition of items to 
be covered by Level I and I.evel II 
cunt rul. 

o 



Flight Manifest 

A compilation of Level I and Level II 
control data for an individual payload 
flight. 


o 

Integrated Planning 

(Planning Baseline 

A summary of payloads and their trans- 
portation requirements w'lthm a six- year 
planning horiaon with preliminary sched- 
ules and reaource utilisation proxies con- 
sistent with budgetary guidelines. Provides 
a standard guide with respect to w-hat 
payloadS) missiuna and flight# are new (or 
modified) in the STS planning data base (and 
serves as a common point of departure 
and reference for detailed planning through- 
out the agency. 


o 


Space Flight Opera- 
tions Plan 

An integrated summary of the pl.ins 
developed by operations centers in response 
to the planning b.iseline. Serves as the 
master ooeraling plan for the director of 
STS operations 



Approval rif Payltiads Flight 
and Supporting Activity 

Program Uperat ng 
Plan (POP) 

Identifies fiscal operating plans and 
requirements for new snd continuing 
projcL Is 

o 



Project Plan 

The planning document which desi nbes 
the overall plan for proceeding with a 
project 

o 



Project Apprtival 
Document tPAD) 

The control document by which new 
projects are approved in NASA 

o 



Flight Approval 
O.irument 

The control document by which 
individual flights sre sppr<wed 


o 


I'rcjpuacd by JSC 
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The Planning Baseline, which contains the requirements for Agency-wide 
planning, is the only major new document specifically generated for the 
SUP proces s . 


The activities described in this section are oriented toward developing the 
planning information necessary to accommodate payloads that are under the 
jurisdiction of NASA. Non-NASA payloads are handled by the SUP process 
in terms of their interfaces with the planning cycle and the Space Transpor- 
tation System. 

4. 1. 1 Development of the Payload Model and Payload Planning Data Bank 
With the assistance of the NASA Associate Administrators, longer-term 
payloads that are projected but not funded are surveyed twice a year (in 
June and January) tr. identify those that are most likely to materialize as 
firm commitments. These "most probable" payloads are added to the list 
of payloads and flights that are already authorized and funded as the result 
of the previous planning-and-budgeting cycles and payloads originating with 
non-NASA sources such as the Department of Defense and the Communica- 
tions Satellite Corporation. 

The payloads whose milestones fall outside the 6 -year horizon are also 
surveyed to identify those which should be considered for future planning. 

All of the above payloads (except for the quick-response variety) are included 
in a Payload Model which is updated annually in August. The preliminary 
version of the model is sent to the Office of Planning and Program Integration 
(OPPI) at NASA Headquarters, which coordinates it for revision and approval. 

For the payloads in the approved Payload Model, STS Payload Data Analysis 
(SPDA) sheets are developed by the payload centers. These SPDA sheets 
provide detailed descriptive data for each payload. When the SPDA's are 
forwarded to SUP by the centers, they are added to the Payload Planning 
Data Bank (PPDB) for use in further analyses and for access by the various 
centers. By this means, the PPDB provides a payload "library" service 
for the agency. 
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4 . 1.2 DeveIopm.ent of the Traffic Model 

Development of the Traffic Model begins with capture/cost analyses. The 
capture analyses compare payload accommodation requirements and orbital- 
activity demands (launch window, retrieval, servicing schedule, etc.), for 
the payloads from the approved Payload Model, with STS capabilities. 

The objective of capture analysis is to assemble mutually compatible payload 
into cargo sets according to various criteria such as maximizing the utiliza- 
tion of available STS volume and weight carrying capabilities while minimi- 
zing the number of flights needed to deliver (and service or retrieve) these 
payloads. 

The results of the capture analyses are combined with SPDA data to produce 
a set of cargo manifests that assemble the payloads in compatible flight 
combinations for tentatively identified mission years for the operational 
life span of the STS. 

These cargo manifests are published twice a year. In order to provide ade- 
quate lead time for mission analysis efforts, a "preview'* cargo manifest 
is I'eleased in the spring (mid -May) based on the January payload survey. 

The appropriate payload centers then initiate preparation of IMAP's for new 
cargoes. The "final" cargo manifests for an individual planning cycle are 
presented in the Traffic Model published in mid-Novembei’ and are substan- 
tiated by the IMAP's developed in the interim. The final cargo manifests 
also pick up any new payloads identified for the first -time in the June payload 
survey and published in the August Payload Model. These new payloads are 
grouped into new or redefined cargoes, which, in turn, lead to assignments 
for new or reassessed IMAP effort for their substantiation on an "as- 
completed" basis. 

Development schedules or procurement milestones and related funding 
requirements are estimated for each payload included in the cargo manifests 
so that the' requirements of the payload traffic can be compared against 
budgetary guidelines. Cost estimates and schedules for approved NASA 
payloads are throughput from the responsible Center or extracted from the 
appropriate Project Approval Document (PAD), It is possible that payloads 
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and flights that are just entering the planning horizon might result in forecasts 
exceeding guidelines. However, with yearly iteration, it is expected that 
the plan will fall within the guidelines as it incorporates the items for which 
firm budget requests are forthcoming. 

The cost data reported out of capture/cost analysis also include "STS cost 
per flight" dollars allocated to each payload. The STS cost per flight allo- 
cations, when summed, provide an indication of the total STS operations 
cost for the payloads included. For non-NASA payloads, these costs are 
separately identified as estimated reimbursements (actual reimbursements 
are determined later per User Charge Policy negotiations for firm payloads). 

The complete set of cargo manifests and schedules (including those for 
approved cargoes and flights) when combined with the cost estimates for 
NASA payloads and STS operations constitutes the Traffic Model. Because 
. it is critical to the future success of STS operations, that portion of the 
Traffic Model involving forecasted payloads must represent the best esti- 
mate possible, and the realism of scheduling and costs must be assured. 
Therefore, the payload schedules and costs are reviewed by the payload AA's 
while capability projections and costs for the STS and its support elements 
are reviewed by the STS Operator. Non-NASA payload organizations also 
review the model with respect to their payloads ' schedules and interfacing 
milestones and cost estimates. 

4 . 1.3 Development of Mission Requirements 

When the Preview Cargo Manifest is published, the appropriate AA 's assign 
responsibility for performing mission analysis for the various cargoes to 
the appropriate payload center s . In the case of the multidisciplinary mis - 
sions, responsibility for mission analysis is assigned by the office of Planning 
and Program Integration. Since the missions undei- consideration are 
generally not approved, no mission manager has been assigned. However, 
an individual is assigned the responsibility to pull the missions requirements 
together as a surrogate mission manager . The mission analyses define the 
payloads for each cargo and establish the feasibility of its overall mission 
by resolving any incompatibilities . The I'esults of mission analyses are 



presented in the form of an IMAP document which presents a description of 
the mission and the required STS flight (or flights, in the case of retrieval 
and servicing), 

4.1.4 Development of the Planning Baseline 

In the STS utilization planning process, the operations centers require 
specific data to support their long-range planning efforts and development of 
their future operational budget requirements. In order to accomplish this, 
the centers need an authoritative list and schedule of cargoes to be flown 
along with specific payload and mission data as noted in Table 5'!'. The 
Traffic Model, SPDA's, and IMAP's can provide the specific payload and 
mission data. However, before using the data in these documents, the 
ability of the STS to accommodate the projected traffic and its requirements 
must be assessed; if there are incompatibilities, the associated technical or 
programmatic problems must be pointed out so they can be resolved either 
in the current planning cycle or, for newly emerging payloads at the far end 
of the planning horizon, in subsequent (yearly) iterations. This includes 
assessments for contingency and quick-response traffic. A Planning Base- 
line Document is proposed which accomplishes the above. It is prepared for 
release in April of each year as an approved guide to enable the STS and 
payload organizations to achieve consistency among their individual planning 
efforts. Simultaneously, finalized SPDA and IMAP data for payloads and 
missions in the Planning Baseline are made available. 

The Planning Baseline (Table 6) presents a summary of transportation 
requirements in the 6 -year planning horizon comparing them on an integrated 
basis with current capabilities to establish their "achievability" (or to expose 
problems). Both emerging and authorized payloads and missions are 
accounted for. Preliminary assessments of schedule and resource utiliza- 
tion also are included. 


^During the course of the study, the operations centers were surveyed to 
determine their needs. The Planning Baseline ■ described in this section is 
designed to satisfy what was desired by the centers (on a collective basis) 
as an input to their planning. 
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Table 5 


DATA NEEDED BY THE OPERATIONS CENTERS 
FOR LONG-RANGE PLANNING 


Data Items Common to All Centers 

• Traffic model/car goes 

• Mission synopses 

• New payloads and missions identification 

• Schedules 

• Quick-response/contingency forecasts 


Data Items for Specific Functions 


Network Data 

Orbital parameters 

Period of support 

Type of service (MA, SSA, KSA, 
other) 

Return/for ward/tracking period 
Data bandwidth /bit rate 
Terrestrial bandwidth /bit rate 
User receiver locations 


Launch Operations Data 

• Special support facilities / 
equipment 

• Special access and PCR require- 
ments 

• Unique operations 

• Hazardous operations 

• Resource requirements (fluids, 
power, area, etc.) 

• Radiation hazards 

• Payload classification constraints 



Flight Operations Support 
Data acquisition requirements 
Period of support 
Real time display requirements 
Off-line computation 
Uplink requirements 
Crew/skill requirements 
Simulation/training requirements 
Special facility requirements 
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Table 6 

PLANNING BASELINE 


• Payload Lists /Project Status and Schedule Summary 

• Mission Synopses and Requirements Summary 

• Traffic Model/Cargoes Summary 

• Flight Schedules 

• Contingency Traffic 

• Resource Base^l^ Utilization/Inventory Profiles and 
Preliminary Assessment 

• Major New Starts /Projects^''!' 

• Integrated Program Milestones and Schedules and 
Compatibility with Budget Guidelines 


':<STS Elements, LRF, MCC, POC, Network 
'!"ITncludes STS Projects as required by Mission and Flight 
Schedule 


Figure 7 illustrates the activities associated with developing the Planning 
Baseline. During the year preceding the publication of the Planning Base- 
line, changes covering new, near-term payloads and flights whose milestones 
have moved into the 6 -year planning horizon are accumulated. Inputs with 
respect to required open cargo manifests and margins for quick-response 
payloads also are accumulated. Headquarters direction is given as to which 
planned new payloads should be included and what priorities should be 
assigned, and as to the status and priorities of previously included projects 
and STS operations. With this data the Planning Baseline can be developed 
after the analyses described in the following paragraphs have been completed. 

4. 1.4. 1 Contingency Analyses 

Contingency traffic is incorporated in the Planning Baseline by estimating, 
through statistical evaluation of past operations and future traffic projections, 
the number of extra flights that must be included in planning. Forecasts 
from the payload organizations of additional flights that may be needed for 
emergencies (e. g.^ replacement of a failed satellite) and/or targets of oppor- 
tunities also are included so that "open" cargo manifests can be provided 
for them. Flexibility to accommodate payload deletions , launch aborts, 
emergency missions (e. g. , repair or replacement of a failed satellite), and 
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Figure 7^ Planning Baseline Development 
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extra missions needed over and above those provided by the open cargo 
manifests is provided by determining and operating under an optimum utili- 
zation factor and flight schedule distribution that allows insertion and/or 
substitution of STS flights, as well as tolerance for "workaround" impact 
on the next flight or two after a contingency. 

4. 1. 4. 2 Integrated Scheduling and Utilization Assessment Analyses 
Integrated scheduling analyses are also performed to provide preliminary 
time phasing for the utilization of the resources necessary to support the 
payload traffic. These analyses are based primarily on the operations flows, 
and timelines in the IMAP's for new missions, the respective centers' pro- 
ject plans for authorized missions and the standard resource and operations 
handbook provided by the Operations Centers (STS, LRF , MCC, NET, etc.). 
These analyses are coordinated with the appropriate centers to assure they 
present a valid picture of what will be needed and can be accommodated. 

4. 1. 4, 3 Data Sources 

In order to preclude overlaying a new management planning system on the 
various centers, the development of the Planning Baseline is predicated on 
using current data which is developed by the various centers in their normal 
course of business. 

Figure 8 summarizes the input sources which are integrated into the Plan- 
ning Baseline. As can be seen, the majority of the input sources are already 
in existence, or are normally produced for new payloads. However, there 
are some new sources of data, or expansions, to existing data sources, that 
appear to be necessary: 

• Headquarters Guidelines - These guidelines are required on 
a semiannual basis and consist of new payloads to be included 
in planning, constraints, approved schedules, budgetary 
plan.ni.ng wedges, and current tariff structure. 

• Spacelab Payloads Integration Plan - A control document 
which summarizes Spacelab payloads and their schedules, 
predicts contingency traffic, and estimates schedule com- 
pliance probabilities for individual payloads /experiments. 
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HEADQUARTERS GUIDELINES [ T 

~ PLANNING GUIDELINES 

-AA'S PAY LOAD LISTS * 

- POP GUIDELINES/BUDGET PLNG WEDGES 

~ FISCAL RESOURCE PLAN ^ 

SUP-RELATED DOCUMENTS 

- PAY LOAD MODEL, SPDA • • 

- CARGO MANIFESTS AND TRAFFIC MODEL • • • 

- COST ASSESSMENT 

SHUTTLE SYSTEMS DOCUMENTS (0700) 

- PAYLOAD ACCOMMODATIONS (VOL XiVI • 

- PROGRAM PLAN STATUS REPORTS 

- C0.ST7FLIGHT PARAMETERS (VOL XVI) 

PAYLOAD PROJECT DOCUMENTS 

-PHASE A/ B STUDIES • • • -3t 

- PAYLOAD PROJECT PLANS AND PAD’S • • • ^ 

- SPACELAB PAYLOAD INTEGRATION PLANS O O O O 

- IIVIAP'S j» ^ 

SPACELAB SYSTEMS DOCUMENTATION 

- PAYLOAD accommodations (SLP/2104) • 

- PROGRAM PLANf'STATUS REPORTS ^ 

SUPPORT OPERATIONS DOCUMENTS 

- STDN (101-1) AND TORS (101.21 USER'S GUIDES ZIIZZZlZIZII- 

- KSC STS USER’S HANDBOOK 

- KSC SHUTTLE PROJECTS SUMMARY lK-SM-03, 1,02.3) 

-JSC FLIGHT SYSTEMS SUPPORT CAPABILITY ZZIZZI 

- POC OPERATIONS capability ^ 

accommodation RESERVATIONS 

- STDN MISSION MODEL (STDN 816) 

- SPACE FLIGHT OPERATIONS PLAnCT) O O 

- SPACELAB ELEMENTS AND LOGISTICS PLAN O 

- POC OPERATION PLANS 

- KSC SHUTTLE PROJECTS SUMMARY | | [ 

NOTE: additional DOCUMENTATION REQUIRED TO COVER WTR AND REMOTE RECOVERY SITES 

• EXISTING DATA 

* recommended EXPANSION TO EXISTING DOCUMENTS 
O REQUIRES NEW DOCUMENTS : 
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© PREPARATION OF THE SFOP IS IN 
PLANNING BY OSF 


Figure 8. Inputs Required for the SUP Planning Baseline 


• JSC Flight Systems Suppoi’t Capabi lity and POC Operations 
Capability - Documents which provide current and projected 
capabilities for STS and payload mission control (how many 
missions can be handled in a given time period, constraints 
on contx’ol center turnaround time, etc.) and manpower and 
new equipment/equipment requirements for increased mission 
rates. 

• Space Flight Operations Plan — The Space Flight Operations 
Plan has been proposed by NASA /JSC to be the NASA Agency 
umbrella for operations planning, including near-term missions, 
payloads, flight hardware assignments, schedules, and direc- 
tional guidelines through 5 years. It includes the "work-to" 
flight schedule, an integrated operations support plan (basis 

of resource commitment by centers), and identifies develop- 
ment plans for any additions to the STS program resources. 

• Spacelab Elements and Logistics Plan — A document which 
presents Spacelab element assignments to PI locations and 
STS flights, and their scheduled utilization with key milestones. 

• KSC Shuttle Projects Summary Books — Should be expanded to 
include accommodation reservations and resource utilization 
profiles for approved missions. 

4. 1.4. 4 Budgetary Planning Assessment 

A basic premise of the SUP system is that all centers will conduct their 
individual planning to the payloads, missions , and schedules assembled in 
the Planning Baseline. Revisions and adjustments to the Planning Baseline 
are accepted from (1) the centers through their respective Associate 
Administrator's input to the next Planning Baseline cycle guidelines, (2) 
Headquarters review and approval, and (3) operation of the POP cycle and 
publication of the Space Flight Operations Plan. Thus, as the Planning 
Baseline is "stepped" (updated) each year, the forward planning years of the 
Planning Baseline and the Program Operating Plans /Space Flight Operations 
Plan of the centers are brought into agreement through this annual feedback 
loop. 
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Part of the "stepping" process is the reconciliation of the Operating Plans 
future funding projections with the NASA Budgetary guidelines. The August 
POP responses from the centers including new initiatives, as well as sus- 
taining and runout funding requirements, are submitted through their 
respective AA's to the NASA Comptroller. The Comptroller uses the POP 
responses, along with NASA Management guidelines, for development of 
line item budget requests and forward (5 -year) plan for negotiations with 
OMB each October. The individual POP future projections are compiled 
by the Comptroller, per NASA Management guidelines, into future budget 
planning "wedges" for each program office. These are associated v/ith the 
new initiatives (payloads, missions, STS projects, etc.) to be accommodated 
in the next Planning Baseline. These new initiative budget planning wedges 
are keyed to the integrated program schedules and project interfaces so 
their total funding impacts can be assessed. The results are added to the 
established sustaining and runout budget and compared to the budgetary 
guidelines. Discrepancies are identified and planning options are developed 
and assessed for resolving these conflicts through project deferrals, sched- 
ule slips /stretch /acceleration, etc. These options are coordinated through 
the Comptroller to arrive at a fiscal resource program plan and schedule 
compatible within budgetary guidelines. Program guidelines and priorities 
provided by NASA management are used in developing and assessing the 
program options. Use of the approved Planning Baseline by the centers as 
a common program reference in preparing their individual POP should help 
minimize post-submittal POP reconciliation requirements. 

4. 1.4.5 Approval 

Upon completion, advanced copies of the Planning Baseline are transmitted 
to the various center s for comment. At the same time it is sent up to the 
Assistant Administrator for Planning and Program Integration for presen- 
tation and approval by the SURE. Upon approval, the STS operations and 
payload centers use the plan as the basis for their indi^ddual planning. As 
part of this planning, the centers develop updated payload schedules, STS 
capability requirements and descriptions, and mission analyses . The 
centers also update estimates of quick-response traffic and open cargo mani- 
fest requirements . These data are then included in the center's planning 
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documentation which in turn then becomes an input to their POP and to next 
year's Planning Baseline. 


4.1.5 Development of Integrated Payload Interface Requirements 
As shown in Figure 9, the payloads in the Payload Model are analyzed to 
establish their collective requirements for interfacing with the STS, support 
equipment, and supporting services. The Traffic Model and associated 
IMAP's are used to establish interface requirements imposed on the STS as 
a function of time and of the combined payload requirements due to payload 
groupings (cargo manifests). 

The integrated interface requirements are compared against the current 
STS and support-element configurations as defined by operations handbooks, 
and assessments are made to define the impacts and approaches for accom- 
modating the requirements by changing the STS or the payload, or by devel- 
oping new MMSE . This work is done under the direction of the STS Payload 
Requirements and Analysis Steering Group (SPRAG) and the Joint Users 
Requirements Group (JURG). The latter represents the European Spacelab 
community. SPRAG also helps to coordinate analyses and data needed from 
the various centers. 

After reviews by SPRAG and Headquarters of the integrated interface require- 
ments, impacts, and accommodation assessment, the Assistant Administrator 
for Planning and Program Integration submits the documentation to the STS 
Payload Planning Steering Group (SSPPSG) for validation (acceptance as 
being appropriate for imposition on the STS). 


When interface incompatibilities are found between items being developed 
(such as the STS Orbiter) and the validated interface requirements that 
must be accommodated in the next 6 years (or requirements that need not 
be met Until later but are deemed fundamentaT to the STS or MMSE element 
in question, and thus should be included during development), SPRAG directs 
the writing of a Review Item Discrepancy (RID) for presentation to the design 
review board responsible for the item under development. For items that 
have been declared operational, an Engineering Change Request (ECR) is 
submitted. If a RID or ECR is accepted, it is tracked as necessary to verify 
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Figure 9. Analysis of Interface Requirements and Carrier Accommodations 














its incorporation and establish its effectivity. The affected interface 
accommodation oi- MMSE data book is then revised and the various centers 
alerted to this change. 


For RID's that are rejected or changes that are subsequently rejected by the 
Change Control Board (CCB) of the element in question, three courses of 
action are possible: (1) define new or modified MMSE to provide the required 

transition across the intei'face, (2) modify the payload, or (3) modify plan- 
ning (i.e., regroup payload combinations that exceed STS capabilities). 
Appropriate analyses and trade studies are performed in conjunction with 
SPRAG to establish recommended solutions and the cycle is reentered through 
the SSPPSG. The Planning Baseline or MMSE Plan is revised accordingly 
and the appropriate payload organization is alerted. 

4.2 SUP SYSTEM ELEMENTS 

The system required to produce these products consists of a planning group, 
technical support services, a data system, and interfaces to the various 
NASA program centers (STS operations, payloads) and to NASA Headquarters. 

4.2.1 SUP Planning Group 

The SUP planning group is aligned to the major SUP products and functions 
as indicated in Figure 10. The SUP Project Management (1.1) provides 
management of the SUP project group as well as coordinates its activities 
with SUP-related activities throughout NASA and other interfacing elements 
(DOD, user community). U sex* Development and Payload Model (1.2) pro- 
vides the central user liaison/coordination for user requirements and 
requests, including quick- response requests . This also includes compilation 
of payload lists and payload data (SPDA sheets ), including on-orbit payloads 
subject to revisits as well as new and planned payloads , over the planned 
operational lifetime of the STS. This element includes establishment and 
maintenance of the Payload Model each August. 

Traffic Model Development ( 1 . 3) performs the preliminary definition of cargo 
manifests through capture analysis using payload data from the PPDB, data 
on the STS accommodations /capability, pianned/requested payload launch 
(or revisit) dates (year), and guidelines and prior traffic projections on STS 
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Figure 10. SUP Work Breakdown Structure 











utilization (includes LRF and network). Preliminary analyses of cargo 
manifests are made to assess payload compatibility and the preliminary 
integrated mission plan/STS compatibility. An update of the cargo manifests/ 
traffic projections is published each May as a Preview Cargo Manifest. A 
traffic model is developed covering the projected traffic (by year and site) 
over the operational life of the STS. 

Cost estimates (by year) are made of the projected traffic using available 
data and Cost Estimating Relationships (CER's) appropriate to identify costs 
to NASA (NASA payloads and transportation) and to users (transportation and 
other NASA reimbursed charges). The costing assessments are included with 
tha updated cargo manifests and traffic projections in the Traffic Model pub- 
lished each November. 


Mission and Flight Assignment Analyses (1. 4) assess cargo manifest 
compatibility in greater depth, develop preliminary integrated mission 
plans, and identify desirable flight dates or flight opportunities. Integrated 
Mission Analysis and Planning reports (IMAP's) are prepared for cargo 
manifests approved for preliminary planning. Most IMAP effort is performed 
by the assigned payload centers with SUP supporting and coordinating as 
appropriate. In some cases, the SUP project group may develop IMAP's 
directly. 

This work area also includes the flight opportunity analysis /cargo margin 
analysis effort in support of preliminary flight scheduling and quick response 
requests. 

Integrated Program Planning ( 1 . 5) translates the near-term portion of the 
Traffic Model, IMAP's data, project plans data, POP guidelines and STS 
operations plans into an integrated program plan as an Agency-wide common 
reference Planning Baseline. 

This planning includes assessment of STS resources utilization, development 
of integrated program milestones, contingency planning, funding/budgetary 
projections /guidelines recommendations, and a preliminary flight schedule. 
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This work area includes coordination of this effort with the STS operations 
and support centers in support of Space Flight Operations Plan (and support 
plans) development. 


Development of Integrated Payload Interface Requirements (1,6) draws on the 
PPDB and IMAP's effort to develop an envelope of payload requirements 
imposed on STS elements. These are assessed against the nominal accom- 
modations and submitted to the SSPPSG for validation. This effort is 
performed in coordination and with the review and approval of the SPRAG 
and JURG . 

One result of the interface requirements effort is the development and update 
of an MMSE Plan (1.7) which identifies requirements and utilization of 
MMSE along with its appropriate programmatic (schedules /funding) assess- 
ments , 

4.2.2 SUP Data System 

The integrated process proposed to tie together the SUP computer systems 
and software programs, data management (data storage, retrieval, and 
display systems), and reports /data production tasks is the SUP Data 
System. It supports the overall NASA planning process which plans and 
schedules the payloads to fly on the STS. 

The SUP Data System provides SUP management and staff with effective 
computer-based support in establishing and operating the SUP process. The 
functional relationships between the different elements of the system shown 
in Figure 11 illustrate its capabilities in data processing, report generation, 
and handling of terminal accessible data banks. The proposed data system 
would utilize established NASA computer hardware and. data bank capabilities, 
for example, the Marshall Information, Retrieval, and Display System 
(MIRADS) for teleprocessing activities . However, some additional automa- 
tion is desirable. As an example, scheduling software that will help assess 
STS resource utilization (in developing the Planning Baseline) appears to be 
needed to efficiently meet the milestones associated with NASA's and the 

Government's planning and budgeting cycle. 
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Figure 11. SUP Data Syitem 
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4.2.3 Program Interfaces 

In performing its functions, SUP interfaces with all NASA elements involved 
with the Space Transportation System as outlined in Table 7. Its interface 
to Headquarters is primarily one in which guidance is received and approvals 
are obtained. Its interface with the Payload Centers is generally associated 
with the collection of payload and payload mission information. The interface 
to the Operations Centers is more or less restricted to maintaining current 
information on the status, capabilities and assignment of STS elements and 
supporting services. 

The SUP project group interfaces with the user community, DOD, and NASA 
payload offices for payload data, the NASA payload centers for mission 
planning, the NASA operations centers for STS data and operations planning, 
and NASA Headquarters for guidance and approval. Figure 12 indicates 
these interfaces and how they relate to the SUP work breakdown structure. 
SUP interfaces to non-NASA payloads (user community, DOD) through its 
Users' Liaison Office and to the NASA Payload Centers through the Payload 
Planning Data Bank (PPDB) Interface Module and the IMAP efforts at each 
center. In connection with user liaison and integrated program planning, 

SUP may interface directly with Mission Managers for Quick-Response 
Request and project planning data. SUP interfaces to the NASA Payloads 
Offices at Headquarters for release of approved Payload Lists in January 
and June of each year — this includes approval of non-NASA payloads for 
planning purposes, as well as NASA payloads. This interface, as well as 
other Headquarters interfaces, is executed through the Office of Planning 
and Program Integration (OPPI) which sponsors the SUP project group. ' 

This includes interface to the NASA Comptroller for POP guidelines and 
budgetary planning data, interfaces to the various NASA Program Offices 
(OSS, OA, OAST, OSF /STS Operations /STS Programs) for planning 
guidance and data and the coordination of Headquarters review and approvals 
of the Traffic Model, The OPPI also provides the SUP interfaces to the 
STS Utilization Review Board (SURB) for review and approval of the Planning 
Baseline and to the STS Payload Planning Steering Group (SSPPSG) for 
review and validation of Integrated Payload Interface Requirements. SUP 
interfaces directly with the STS Payload Requirements and Analysis Group 
(SPRAG) and the (Spacelab) Joint Users Review Group (JURG) on the develop- 
ment and review of the payload interface requirements. 
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Table 7 

SUP FUNCTIONAL INTERFACES INTERNAL TO NASA 


NASA Headquarters 

SUP Function 

Payload Centers 

STS Operations Centers 

Referral of users to 
SUP 

Payload-user liaison 
and requirements 

Candidate payload 
descriptions 


Notification by SUP 
of recommended 
assignment 

Quick response 
flight opportunity 
analysis 

Access SUP data base 

Recommended flight 
assignments for QR 
payloads 

AA recommenda- 
tions, Coordinate 
and approval pay- 
load model 

Payload model 
preparation 

Response to "SPDA 
call" 


Technical and fiscal 
guidelines and plans 

Capture/cost analysis 
(cargo manifests) 

Furnish summary pay- 
load program data : 

Furnish current and pro- 
jected STS capabilities 

Review and approve 

Traffic model prep- 
aration (cargoes 
plus traffic plan) 


Long- range planning 

Planning guidance, 
review, and approve. 

Planning baseline 
(near term) 

Advise, review for 
input to planning 

Advise; review for input 
to planning 

Review options and 
select groupings 

Prepare mission options 
(multiple users) 

Advise 

Advise 

Responsibility 
assignments for 
missions 

Coordinate integrated 
missions analysis 

Provide integrated 
missions analysis 
(IMAP) 

Provide STS accommoda- 
tions, operations and 
capability definitions 

Coordination, 
review, and approve 

Advise and support 

Advise and support 

Prepare space flight 
operations plan 

STS Payload Planning 
Steering Group 
Validation 

Integrated payload 
requirements synthesis 
and SPRAG coordination 

Payload interface 
requirements develop- 
ment, SPRAG support 

STS accommodation 
descriptions /handbooks 

SSPPSG validation 

MMSE requirement and 
equipment identification 

Payload interface 
requirements, SPRAG 
coordination 

STS accommodation and 
MMSE description 

SUP RID/ECR 
recommendations 

Support RID/ECR 
preparation 

Prepare RID's and 
support milestone 
reviews 

Act on RID's and ECR's 


OElGW^i' 

auAuma 
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syii^nocr 


CR63 


PAYLOAD OFFICES 
(PAYLOAD LISTS) 


NASA 

COMPTROLLER 

OFFICE 


STS UTILIZATION 
REVIEW BOARD 
(SURB) 


OFFICE OF 
SPACE FLIGHT 


STS PAYLOAD PLANNING 

• 

OFFICE OF STS 

STEERING GROUP 

PROGRAM INTFGRATION 

OPERATIONS 

(SSPPSG) 

T 



1.1 SUP PROJECT OFFICE 


DOD/SAMSO payload PROGRAMS •- 

t — - — 1 

USER COMMUNITY PAYLOADS r 


1.2 USER 1.3 TRAFFIC 

DEVELOPMENT MODEL 

AND PAYLOAD DEVELOPMENT 

MODEL 


PAYLOAD CENTERS 

INTEGRATED MISSION ANALYSIS 
AND PLANNING (IMAP'S) 

PAYLOAD DATA MODULE (FPDB) 

MISSION MANAGERS AND FAD 


STS PAYLOAD REQUIREMENTS 
and ANALYSIS GROUP 

JOINT USERS REQUIREMENTS 
GROUP . 

STS/PAYLOaO INTERFACE RID'S/ECR'S 


1.5 MISSION AND 
FLIGHT 
ASSIGNMENT 
ANALYSIS 


1.6 INTEGRATED 
PAYLOAD 
INTERFACE 
REQUIREMENTS 


1.4 INTEGRATED 
PROGRAM 
PLANNING 


17 MULTIUSE 
MISSION 
SUPPORT 
EQPT 


STS OPERATIONS CENTERS 

SPACE FLIGHT OPERATIONS 
AND SUPPORT PLANS 

STS CHANGE CONTROL BOARDS 


Figure 12. SUP Program Interfaces 











Section 5 

SUP SYSTEM IMPLEMENTATION 

Development of the SUP system requires completed definition of the process 
and products, initiation of the process — using nonautomated techniques as 
necessary to produce prototype products — while completing definition and 
development of the required SUP (automated) data systems. The Planning 
Baseline document and related data systems are the major development 
efforts since most of the remaining documents and data systems already 
exist or are already in development. 

5.1 SCHEDULES 

The development schedules for the SUP system are presented in Figure 13. 

To include the start of STS flight testing (OFT) in 1979 and subsequent 
years within the SUP horizon, the production of SUP documentation should 
get underway in 1976 so that current documentation (Payload Model, Traffic 
Model, etc.) can be updated and a Planning Baseline prototype can be 
published by May 1977. This would also allow at least one yeax' for itera- 
tion of planning and development of the first Space Flight Operations Plan 
before firm budgets are negotiated for operations beyond OFT, and the 
operation of the planning system could be validated at an early date. Thus 
the first operational SUP cycle is initiated in Februai*y 1977 leading to 
first issue of an operational Planning Baseline in May 1978. This is followed 
in October 1978 by the first operational version of the Space Flight Opera- 
tions Plan. This development schedule is shown in Figure 8 as it relates 
to the orbital flight test and IOC of the STS. 

6.2 STS UTILIZATION PLANNING MANPOWER 

The manpower requirements associated with SUP operations were estimated 
in "bottom-up" fashion. Manpower for each individual task in the SUP process 
was estimated on the basis of manpower utilization on similar efforts in other 



47 


CALENDAR YEAR 


1976 

1977 

1978 

1979 

1980 

1981 

1982 

1983 

1984 


OFT 

(6-FLT PROGRAM) 


A A_A A^. 

3 -4 5 6 


SPACELAB 


^SSSSSSSSSSSSm 


PROTOTYPE 
PLNG B/L 
(FY79-83) 


FIRST ISSUE 
PLNG B/L 
(FY 80-84) 

A 


PLNG B/L NO. 2 PLNG B/L NO. 3| 
(FY 81-85) (FY 82-86) I 

A A I 


SPACE FLT SPACEFLT 2 
OPS PLAN OPS PLAN FY ’80 

NO. 1A 

FY '78 /1-— - ■— ---N.Unv-T 


SFOP NO. 3 


FY '81 

STS OPERATIONS 


GOV'T ' 

APPROVALS AND 
AUTHORIZATIONS 


START 

B I C/D APRODUCTION 

systeivlV system^^^^^^^<^^ 

DEFINITIOI^^^YELOPMENT^^ 


SUP PLANNING 
Yy CYCLE FOR 
/Y F Y '81 THRU '85 ■Y/^ 

SUP PLANNING 
Ypi F ;Z CYCLE FOR 
'////■/ FY '80-'84 


FISCAL YEAR 


Figure 13. STS Development Schedule and SUP System Development Timetable 


























programs. Where experience on similar activities was not available, direct 
estimates were made that considered the nature of the task and its output. 
These estimates were then included in a SUP process simulation, and the 
results are summarized in Figure 14 with respect to mission rate. 

The simulation indicated estimated total manpower needs ranged between 
100 and 160 men. This includes the manpower required to perform integrated 
mission analysis and planning (IMAP) for each mission. The manpower to 
perform STS utilization planning only — exclusive of IMAP effort — is approx- 
imately 60 at the 30 missions /year level with only moderate increases with 
mission rate. 

The SUP implementation phase (excluding IMAP) requires about 60 to 70 
men (NASA and contracted), with about half developing the SUP Data System 
until late in 1976 when prototype production jumps total requirements to 
about 100 men. The implementation effort phases into the operational phase 
with the start of the SUP multicycle manloading in 1977. 

It is emphasized that the manpower requirements cited here are strictly a 
result of the study effort, and that although selected tasks were discussed 
with NASA, the overall assessment is an independent MDAC product. 



MANPOWER 



ALL NEW AND DETAILED 
ANALYSIS MISSIONS 


MORE MISSIONS WITH: 

• REPEATING FLIGHTS 

• SAME CONFIGURATION 

• LESS DETAIL 


EST SUP 

MANPOWER 

RANGE 


INCLUDES IMAP 
MANPOWER 


20% ARE NEW 
80% ARE REVISED 


SUP ONLY 
(EXCLUDING 
IMAP EFFORT) 


MISSIONS PER YEAR 


Figure 14. STS Utilization Planning Manpower 


Section 6 

RECOMMENDATIONS 

The following items are recommended for consideration: 

A. A centralized STS/Spacelab payload utilization planning office should 

be initiated in the near future (1976-1977 time frame). 

B. The major functions of this office are; 

1. Maintain and update a catalog and centralized data base of 
potential payloads and their descriptions, accessible for agency- 
wide planning. 

2. Group the s-j ’payloads, through capture analyses, into potential 
flight cargoes for long-range (12- year) traffic projections, 
updated semiannually, for agency- wide assessment and planning. 

3. Prepare and update (annually) an agency- wide common planning 
baseline of the first six years of this projected traffic with con- 
sideration of integrated program milestones, contingency traffic, 
accommodations constraints, and funding guidelines. 

4. Coordinate, support, and perform analyses of the projected 
payload groupings to assess cargo compatibility and mission 
feasibility. 

5. Determine the envelope of integrated payload/STS interface 
requirements, including those produced by the cargo groupings 
and assess their potential impact on the STS accommodations 
(coordinated with SPRAG and JURG). 

6. Identify and define potential MMSE requirements and concepts in 
response to the assessed integrated payload interface 
requirements. 

C. A process for accommodating quick- response and contingency pay- 

loads should be provided which; 

1. Identifies and describes the payload and the reason for the 
quick- response request (subject to approval). 

2. Identifies the potential flight opportunities in the planned traffic. 
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3. 


Provides for approval at the levels appropriate to the impact of 
accommodating the request on a selected flight. 

D. Flight manifest and flight approval documents should be provided for 
control and approval of multipayload, multiprogram mis sions. 

E. A NASA Headquarters level review and approval board with 
representation from the various NASA program offices (OSF, OSS, 
OA, OAST) should be established for approval of multiprogram 
planning documents (i. e. , the Planning Baseline) and multiprogram 
missions having Level I impacts. 

F. A User Liaison office should be established in the near future as an 
easily identified and accessible interface for potential STS users 
(non- NASA) to propose or request missions and to receive guidance 
and support in pursuing valid proposed uses of space. 
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